This pull request is a fondation in order to prepare the followings:

• enable a libyang+FRR CI on each libyang pull request
• start using libyang3 whenever possible in order to anticipate issues while libyang2 remains the main version to be used.

So does it mean that we are ready to have a d-day that switches the libyang versions ? without any overlapping.

Frankly, I do agree that it would be simpler and it would enforce a quick alignment for the the CIs, distros, etc.

For the packaging of libyang2/3, would you have a good pointer I could start with ?

That's what we did with libyang2, so I don't think there's any problem with upgrading to libyang3 without keeping compatibility with older versions.

Regarding the packaging, I suppose we should just ask @mwinter-osr and @Jafaral to start packaging libyang3. But I don't see yet the official release of libyang3, so we should probably wait a bit until it's actually released.

For libyang3, there are some ABI changes, so it cannot be a smooth transition.

I would like to start before libyang3 will be officially released in order for FRR to set some alignments with libyang3.

Should we consider adding shims for these apis that may/will change in the future? I'd prefer shims to repeated conditional blocks.

For libyang3, there are some ABI changes, so it cannot be a smooth transition.

I would like to start before libyang3 will be officially released in order for FRR to set some alignments with libyang3.

This only affects FRR 10.1+, but if it backward compatible with with 10.0, then we can build packages libyang 3 packages and have that available in our package repos. It it doesn't work with 10.0, it is a bit tricky since our stable version is going to be 10.0 for a while, and we can't publish packages to stable if it breaks 10.0.

We're already publishing both libyang and libyang2 packages at the same time. What's the difference here? It's new packages named libyang3, libyang3-dev, etc. There shouldn't be any conflicts with 10.0 as it depends on libyang2.

@idryzhov : enclosed a minimalist changeset based on our discussions and an update of the libyang's.headers.

the CI/topotests on master with libyang2.2.8/libyang.so.3 is successful on my local setup.
It means that this patch is OK with both libyang.so.2 and libyang.so.3 (assuming FRR is recompiled respectively).

notes:

• once merged, libyang will be extended with a CI that shall run on its/libyang devel branch in order to run some basic FRR checks using a set of FRR tag
  https://github.com/vjardin/libyang/actions/runs/8679016443
• link to libyang+FRR's comments: FRRouting + libyang build CESNET/libyang#2205 (comment)
• libyang with a wide set of topotests: https://github.com/vjardin/libyang/actions/runs/8707858681

using the following package, it should not overlap with libyang2, so both libyang3 and libyang2 can be installed:

$ dpkg -c libyang3_2.2.10-1_amd64.deb

drwxr-xr-x root/root         0 2021-05-04 22:20 ./
drwxr-xr-x root/root         0 2021-05-04 22:20 ./usr/
drwxr-xr-x root/root         0 2021-05-04 22:20 ./usr/lib/
drwxr-xr-x root/root         0 2021-05-04 22:20 ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- root/root   1327064 2021-05-04 22:20 ./usr/lib/x86_64-linux-gnu/libyang.so.3.0.10
drwxr-xr-x root/root         0 2021-05-04 22:20 ./usr/share/
drwxr-xr-x root/root         0 2021-05-04 22:20 ./usr/share/doc/
drwxr-xr-x root/root         0 2021-05-04 22:20 ./usr/share/doc/libyang3/
-rw-r--r-- root/root       993 2021-05-04 22:20 ./usr/share/doc/libyang3/README.Debian
-rw-r--r-- root/root       150 2021-05-04 22:20 ./usr/share/doc/libyang3/changelog.Debian.gz
-rw-r--r-- root/root      3862 2021-05-04 22:20 ./usr/share/doc/libyang3/copyright
lrwxrwxrwx root/root         0 2021-05-04 22:20 ./usr/lib/x86_64-linux-gnu/libyang.so.3 -> libyang.so.3.0.10

Please fix debian/control

done @mwinter-osr

one or two line wrap lint suggestions we should probably pull in before merging ...

one or two line wrap lint suggestions we should probably pull in before merging ...

done @riw777